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I. INTRODUCTION 



Current software engineering practices are based on a 
development model which is 10 to 15 years old.. This model 
is often referred to as the waterfall model. The waterfall 
model shews the development of software as a series of 
discrete steps [Ref. 1, 2, 3, 4, and 5]. 

Experience indicates, however, that software development 
is net as discrete as the model indicates, so the mcdsl has 
been refined by adding loops between each of the steps. 
Furthermore, as software maintenance has gained recognition, 
there is increased pressure to refine the waterfall model to 
show the added importance of maintenance in the software 
life-cycle . 

The software engineering profession's concern about 
software maintenance, which is mere properly termed refine- 
ment and enhancement, has prompted several conjectures. 
Dodd [Ref. 20] has suggested that the current cycle of 
develop, implement, refine and enhance, implement, refine 
and enhance, implement, and so on is really the construction 
and refinement of a prototype system. 

Several other authors have suggested that we should 
develop software prototypes as an alternative to the tradi- 
tional, or waterfall, approach to software development 
[Ref. 68, 36, 62]. Their principal argument is that the 

process of software development is really iterative, slowly 
expanding toward a completed system. Other reasons include 
enhanced communications between the user and designer, fewer 
requirements problems, quicker turnaround between initial 
system need and initial system implementation, to name a 
few. 
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developing a software prototype has 
e appeal for users and managers; they 
cut before committing themselves' to a 
er unsatisfactory or undelivered. Aside 
the benefits often cited, there seems 
icn about the principles underlying the 
are prototypes. 

sents one view of how the process of 
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heory and software design specifically . 

an integrated set of design elements 
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I relates these design elements to soft- 
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Chapter IV introduces the software prototype. The 
process of devaloping software prototypes, their roles as 
models, construction strategies, and the principal uses of 
prototypes are described. The chapter concludes by shewing 
how prototypes support the design elements from Chapters II 
and III. Chapter V briefly describes the essential features 
cf seftware engineering environments, especially those 
features which are needed for developing software proto- 
types. Chapter VI presents four case examples which illus- 
trate the process of developing a software prototype. These 
cases were chosen because in each of them there was an 
explicit decision to use prototypes. Chapters VII and VIII 
present Conclusions and Recommendations for Further Study. 



1 To paraphrase 
design is design. 



Gertrude Stein; 



Design is design is 



II. MODELS OP DESIGN METHODS 



A. STBOCTOBED MODELS OF DESIGN 

The ideas about design and design methods have undergone 
some significant changes in the last 20 years. The early 
models placed their emphasis on the process of design. 
These models had a rational, discrete notion of design in 
which the design process was thought to be a seguence of 
well-defined, highly structured activities. Many theorists 
applied the ideas and principles of the scientific method to 
the process. Alexander [Bef. 6] was one of the earliest of 
the design theorists to carefully explain design. His three 
most significant contributions were: 

1. The symmetry of the design problem — that is, design 

has two symmetical parts, the for m (the solution to 
the problem) and the c ont ext (the setting which 
defines the problem) . "... adaptation is a mutual 

phenomenon referring to the context's adaptation to 
the form as much as the form's adaptation to it's 
context ..." The design problem is an effort to 
achieve "fitness" between the form and it's context. 
[Bef. 6 ] 

2. The formal decomposition of a set of requirements 
into successively smaller subunits. 

3. The importance of diagrams in design. A diagram, for 

Alexander, is "[a]ny pattern which, by being 

abstracted from a real situation, conveys the phys- 
ical influence of certain demands or forces ..." 
[Bef. 6: p. 85] 
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Alexander chose tc emphasize the process of deccmpostion 
in his early work. This process was divided into two 
phases, analysis and synthesis. 

In analysis, the designer, faced with a problem, derives 
a mental picture — often zague and unsatisf actory--of the 
demands of the context, and then decomposes that picture 
into sets (a mathematical picture) . Synthesis begins by 
developing diagrams (based on the sets) , using the diagrams 
to form a design, and then deriving the form (see Figure 
2.1). Alexander also discussed evaluation (he calls it 
"goodness of fit"). Goodness of fit is determined by one of 
two criteria, experimental or non-experimental. The experi- 
mental criterion is trial and error where "[t]he experiment 
of putting a prototype form in the context itself is the 
real criterion of fit." [Bef. 6: p. 21]. The ncn- 

experimental criterion is "(a] complete unitary description 
of the demands made by the context ..." [Ref. 6: p. 21]. 
Alexander believes that: 1) trial and error is too expensive 
and too slow and 2) there is no theory which can express 
"... a unitary description of the varied phenomena of a 
particular context." [Ref. 6: p. 20]. For these reasons 
he concentrates on the proc ess of decomposition. 2 

Alexander's structured view was shared by many theorists 
during the early 1960's. [Ref. 8, 7], Archer [Ref. 7] 
thought of design as a goal -directed activity. The goals or 
objectives cf the problem define the properties required in 
the solution. The details cf the design are the designer's 
decisions about how tc implement those properties [Ref. 7: 

p. 286]. 



2 Alexander devotes an entire Appendix to the 
"Mathematical Treatment of Decomposition." 
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Figure 2.1 Alexander's Design Phases 



Archer identifies three components of the design 
process : 

1. The advance through the project and through time; 

2. The branching cf the problem into its logical parts; 
and, 

3. A problem-solving process cyclically moving through 
subproblems (using a 30-step reiterative operational 
model) . 

Jones [Hef. 8] called the three stages in his view of 
the design process divergence, transformation, and conver- 
gence. He was quite convinced that designers should think 
cf these stages as separate: 

...there is little doubt that their separation is prere- 
quisite to whatever changes of methodology are necessary 
at each stage before they can be reintegrated to form a 
process that works well at the systems level. [Hef. 8: 
p. 64] 



E. WICKED IBOBLEMS 

These early models were often criticized. One critique 
suggested that design problems are "wicked problems" and are 
not, therefore, amenable tc structured analysis (and decom- 
position). The term "wicked problem" refers to a 

. ... class of social system problems which are ill- 

formulatsd, where the information is confusing, where 
there are many clients and decision-makers with 
conflicting values, and where the ramifications m the 
whole system are thoroughly confusing. [Ref. 9] 

Wicked problems have the following properties : 

1. Wicked problems ae ill-formulated. They have no 
definitive formulation and any formulation will 
correspond tc the formulation of the solution. This 
means chat any time a formulation is made, additional 
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questions can be asked and more information can bs 
requested. This also means that the information 
needed to understand the problem is determined by 
one's idea or plan cf a solution. In other wcras, 
whenever a wicked problem is formulated there must 
already be a solution in mind. 

2. Wicked problems have no stopping rule. Any time a 
solution is formulated, it could be improved or 
worked on more. One can stop only because one has 
run cut of resources, patience, etc. (An architect 
cculd keep modifying and improving a design solution 
fcrever--he steps because he has exhausted his fee, 
because the building has to be finally built, or 
because he has exhausted some other resource.) 

3. Solutions to wicked problems cannot be correct or 
false. They can only be good or bad. (There is no 
correct or false building: there can only be a "good" 
building cr a "bad” building.) 

4. In solving wicked problems there is no exhaustive 
list of admissable operations. Any conceivable plan, 
strategy or act is permissable in finding a solution 
and nene can be perscribed as mandatory. 

5. For every wicked problem there is always mere than 
cne possible explanation. The selection of an expla- 
nation depends on the employed world-view; the expla- 
nation also determines the solution to the problem. 
(The high cost of construction of a building may be 
attributed to the " expensive' 1 design, to the high 
ccst of materials, to the wages demanded by unions, 
to high interest rates and inflation, etc.) 

6. Every wicked problem is a symptom of another* "higher 
level" problem. (If the maintenance of the residence 
is "too expensive" tc its inhabitants, this indicates 
that there is a problem with the income of its inhab- 
itants. ) 
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No wicked problem and no solution to it has a defini- 
tive test. In ether words, any time any test is 
"successfully" passed it is still possible that the 
sclution will fail in some other respect. (If large 
windows are designed for a residence to provide the 
desired views, the heating of the residence may 
become too expensive.) 

8. Each wicked problem is a "one shot" operation. There 
is nc room for trial and error, and there is no 
possibility for experimentation. (A house is 
designed and built--there is no going back to the 
beginning to redesign and rebuild it.) 

9. Every wicked problem is unique. No two problems are 
exactly alike and no solutions or strategies leading 
to solutions can readily be copied for the next 
problem. (Even if two residences are designed for 
the same family, under the same geographical condi- 
tions they will never be identical.) 

10. The wicked problem solver has nc right tc be 
wrong — he is fully responsible for his action. 

If design problems are considered as wicked problems, 
they are certainly incompatible with the early models of 
design. The early models clearly separated the pr oblem from 
its solution. With wicked problems, one cannot "define the 
problem" — they have no definitive formulation. If one 
followed the procedures of the early models of design, one 
should be able to establish when a solution was clearly 
found. Wicked problems, however, have no stopping rule. 
Some cf the proponents of the early models of design devised 
tests for design solutions. Alexander argued that trial and 
error should eventually lead to "good fit"; unfortunately, 
each time a solution is tried, the problem is also changed. 
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C. ACCUMULATED KNOWLEDGE MODELS OF DESIGN 



1. Des ign is Argu me ntat ive 

Other design models were proposed following the criti- 
cisms of the early, structured models of design. Rittel 
[Bef. 13] views the whole design process as sequential 
problem solving in which the cycles form networks. An 
essential part of this model is the continuous feedback 
between the designer and the problems environment. Rittel 
calls this 'argumentation': 



. . . . the designer [is] arguing toward a solution with 
hrmself and with ether parties involved in the project. 
He builds a case leading to a better understanding of 
what is to be accomplish ed. In its course, solution 
principles are developed, evaluated in view of their 
expected performance and decided upon. The parties 
commit themselves to specific courses of action and to 
the risks involved in them. In this way, better formu- 
lations of the problem are being developed simultane- 
ously with a clearer and clearer image of the solution. 
[Ref: 13 : p. 19-20] 



If arguments are improved procedurally , their content may 
improve and the products of the design — design 

decisions — may also be expected to improve. While 'argu- 
ing', the parties may gain new insights about the issue, 
expand their world-view, modify challenged positions, and 
learn more about other world-views. 

2. Eat ter ns in E esign 

Alexander introduced the concept of pictoral 
diagrams in design in 1964 [Bef. 6]. Significantly, 
Alexander believed that the design diagrams were produced by 
for mal, rigorous anal ysi s, a design process founded cn math- 
ematical decompositicn. Since then, Alexander and ethers 
[Ref. 10] have concentrated on the diagrams (or Patterns) 
rather than the process. 
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Alexander's patterns are not a resalt of rigorous 
analysis. Rather, design is a process of acquiring knowl- 
edge and then making decisions which reflect that knowledge. 
The crucial issue for Alexander is the availability of 
knowledge. That is, the design decision depends on the 
accumulated knowledge of the designer. Patterns help to 
provide the designer with the necessary knowledge to solve 
the problem. The pattern forms the basis of communication 
between the designer and the client. A pattern — a diagram 
of what the designer knows and believes important for the 
problem--is designed and then passed to the client. The 

client either accepts or does not accept the pattern. In 
either case, both the client and the designer gain new 
knowledge: if the pattern is not accepted, the designer 

proceeds to change the design. 



3 • Design as Lear ning 



Eazjanac [Ref. 15] views the design process as 
formulating the problem and proceeding with a search for the 
definition of the solution. He emphasizes that the formula- 
tion cf the problem is not final. The formulation reflects 
the understanding of the problem, based on the designer's 
knowledge, at that time. 



Any solution ... is already basically determined by the 
definition of the problem. So the "search for solution" 
is then the search for the definition of the specific 
solution which best fits the knowledge the designer has 
at that time. Cnee the specific solution is defined it 
is documented. Documentation may start during the defi- 
nition cf the problem and continue sporadically during 
the definition of the solution--in fact, all three 
phases may at times take place simultaneously. The 
ultimate purpose of the documentation is to communicate 
the definitions of the problem and the solution; its 
immediate purpose is to aid the designer in the defini- 
tion cf the problem and the solution--to help him detect 
new aspects of the problem and the solution and to 
detect inconsistencies in his view. [Ref. 15] 
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4 . Des ign is Sat isf ici ng 

As the designer and user learn more about the 
problem and as the sclution becomes clearer, more and more 
design decisions are negotiated [Bef. 13, 15]. Since these 
design decisions are reached through compromise, they cannot 
be called optimal, in the sense of management science and 
operations research. 

Simcn [Bef. 14] has introduced the idea of satis- 
ficing tc describe these kinds of negotiared decisions. 
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D. DESIGN AS A TECHNOLOGICAL ACTIVITY 

Cross and others [Ref. 16] have proposed a vi.ew of 
design which requires the explicit acknowledgement of the 
organization's role in design. 

'Technology' ... clearly denotes more than just hard- 
ware, and involves, at the very least, consideration of 
the organizational systems within which machinery is 
designed, commissioned, operated and paid for. 
•Technological' achievements, whether those of building 
a irajcr bridge or putting a man on the moon, are as much 
organizational feats as technical ones. [Ref. 16: p. 

190 ] 

These ccnsidera ticns lead to their view that a "satis- 
factory" definition of technology has the following charac- 
teristics: 

1. Technology is orient ed toward practical tasks. 

2. Technology relies on different kinds of organized 
knowledge, of which scientific knowledge is only one. 
Craft knowledge, design knowledge, and organizational 
and managerial skill are others. 

3. Technological activity takes place in an organiza- 
tional context. [Ref. 16: p. 198] 

Cross and ethers devote a great deal of space to 
highlight the difference between knowing "what to do" 
(scientific knowledge) and knowing "how to do" (design and 
craft knowledge) . Their main point cannot be ignored: the 

organization plays as large a role in design as does the 
individual. 

E. DESIGN IS EVCLUTICNARY 

The early models of design were frequently criticized for 
their linear, step-by-step view of design. Page [Ref. 11] 
warned that the design process is not executed straight from 
analysis to evaluation: 
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....in the majority cf practical design situations, by 
the time you have produced this and found out that and 
made a synthesis, you realize you have forgotten to 
analyze something else here, and you have to gc around 
the cycle and trodcce a modified synthesis, and so on. 

In practice, you gc around several times. 

Ellinger stated that the iterative approach to design " ... 
is pariculaily suited to novel projects of some complexity.” 

[Ref. 12: p. vi ] 

Smithies [Ref. 17] has suggested that there are a number 
of essential stages in design. The first stags, design 
analysis, is the statement cf the problem, ?. The next 
stage consists of finding one or more tentative solutions, 
IS. This sclution is then criticized, C. When the designer 
criticizes the solution, he or she admits that the problem 
statement was inadequate. So, the designer re-states the 
problem and begins anew. 

P1-TS1-C1-P2-.. . -Pn . 

Smithies attributes his views about design to Pepper 
[Ref. 18], Popper believes that the process or activity of 
understanding can be represented by a genaral scheme of 
pr ob lem solving b v co je c tur e a nd crit i cism . Popper's 

scheme, adapted by Smithies, is this: 

PI- TT-EE-P2. 

PI is the initial problem statement; TT, the 'tentative 
theory', is the conjecture. EE, 'error elimination', is the 
critical examination of the conjecture. P2 is the new 
problem statement which emerges from the examination. It 
leads tc another attempt, and so on [Ref. 18 : p. 164]. 

Smithies' design stages and Popper's problem-solving scheme 
are very much like Polya's [Ref. 19] method for solving 
problems. Software designers should take note: Polya is a 

mathematician. Popper is a philosopher, and Smithies is an 
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architect, yet each approaches the solution to a problem in 
the same way. 

The progress or the designer through these stag'es is 
marked fcy increased knowledge and shifting priorities. 
Clearly that progress is not linear and should be called 
evolutionary. 

F. SDMHJBI 

Several points about design have been made in the 
proceeding sections: 

1. Design is symmetrical and adaptive; 

2. The interesting (i.e., large, complex) design problems 
can be considered as wicked problems; 

3. Communications with the end user are crucial and 
depend to a large degree on patterns which bridge the 
communications barrier between designer and end user; 

4. Design is a learning process — each party brings a 
different perspective to the problem (and the solu- 
tion!) and leaves (or should leave) with an augmented 
perspective; 

5. Design is satisficing; 

6. Design takes glace in an organizational context; 

7. Design is evolutionary. 

The separation of these points should not be miscon- 
strued. Each of these aspects is interrelated and to a 
certain extent mutually dependent on one another. When we 
say that design is evolutionary, we also imply that design 
is symmetrical and adaptive. When we say that design is an 
organizational activity, we also imply that there will be 
extensive communication during design. whenever we try to 
understand the problem, to learn more about our tentative 
solution, we are raising a problem of understanding, or 
posing a higher level problem, which implies that design 
problems are wicked problems. 
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This interrelated set of design elements forms the tack- 
drop for the remainder of this work. The following chapter 
presents evidence frcm the literature that each of the 
design elements described above is a factor in software 
design. 
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III. SOFTWARE DESIGN METHODS 



A. SOFTWARE DESIGN IS SYMMETRICAL AND ADAPTIVE 

Several instances in the literature point to the 
symmetry cf the software design problem. That is, the solu- 
tion not only depends on the problem, but the problem 
depends cn the solution. Solution and problem are nor sepa- 
rate issues, rather they are intertwined, much like the 
figure and ground in a painting or picture. Each depends on 
the ether. Unfortunately, most people associated with soft- 
ware design do net appreciate this point. Peters points cut 
that software designers complain bitterly that requirements 
are poorly defined while customers and analysts often 
complain that the design is not responsive to the problem or 
problems as they see them. [Ref. 23 : p. 67]. Peters 

wasn't the first to recognize this, though. Podolsky wrote 
a humorous article in 1977 [Ref. 24] where he states "Peer's 
Law" : 

Peer' s Law 

The solution to a problem changes the problem. 

Several ether authors [Ref. 25, 26, and 27] have also recog- 
nized that the problem definition tends to evolve as the 
designers try to bound the problem, or modify the require- 
ments. McCracken and Jackson [Ref. 27] have gone so far to 
say that this dependence is analogous to the Heisenberg 
Principle: Any system development activity inevitably 

changes the environment out of which the need for the system 
arose . 
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Much effort is currently devoted to requirements defini- 
tion and yet inc cmpleteness , ambiguity, and poor definitions 
in requirements documents are often pointed to as the' fore- 
most problems facing software designers today. The effort 
which is spent on completely specifying the user's require- 
ments will gain nothing if software design is adaptive. 

McCracken and Jackson believe that systems requirements 
can never be stated fully in advance. To assert otherwise 
is to ignore the fact that the development process itself 
changes the user's perceptions of what is possible, 
increases insights into the applications environment, and 
often changes the environment itself [Ref. 27: p. 31]. 

Peters says that although reguirments may have been very 
fixed at the beginning, they tend to change and evolve with 
time. If for no other reason, the user's perception of the 
problem changes as dees the designer's perception of that 
problem [Ref. 23: p. 70], 

Change is inevitable during software design, and yet 
"planning fer change" has long been given lip-service, at 
best. Neumann believes that planning for change is slowly 
being recognized as an important end in itself — and one that 
usually cannot be achieved by retrofits into an inflexible 
design [Ref. 28]. 

B. DESIGN IS SATISFICING 

Mcst computer system developers will immediately argue 
this point. Developers of military systems would argue the 
longest and hardest. Why should the idea of satisficing be 
so controversial? Perhaps the answer lies in the past, when 
machine time was expensive and computer memory limited. 
These limitations do not exist at the same level today. In 
fact, satisficing occurs all the time. Conn states that the 
requirements for state-of-the-art systems are ofzen scaled 
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dew n tc respond to the need to cut the overall expense of 
the project or to meet time limitations [Ref. 26: p. 403], 

Designers are, or should be, constantly aware of the -trade- 
offs that are made in systems development, especially the 
classic trade-off, cost versus performance. 

Several authors point out that a user should, in fact 
must, sacrifice an optimum design for a design which can 
cope at a satisfactory level [ Bef . 29, 30]. John Munsun has 
been quoted as saying: 

Users must look at the economics involved in automation 
as a software- prod uctivit y solution. If a user can buy 
a payroll program that is almost what he needs for 
$10,000 cr one that exactly fits his needs for $1 
million, ha must look at the trade-offs and reduce his 
expectations. [Ref. 30 : p. 66] 

Satisficing has to do with more than economics. 
Lawrence Peters has said that the trade-offs for execution 
efficiency and ease of change must be evaluated and a 
compromise made. [Ref. 30]. Lockett emphasizes the role of 
user satisfaction when evaluating trade-offs. For her, user 
satisfaction is not based solely on the functional capa- 
bility of a system, but on useability, reliability, and 
performance as well. Often the user cannot have everything 
(for example, both performance and functional capability) he 
cr she wants in a system. The final product may be the 
result of compromise. Certain functional capabilities may 
be eliminated to achieve specific performance goals or, on 
the ether hand, the user may be willing to sacrifice 
performance to obtain some functional capability [Ref. 31 : 
p. 157], 

Several ether authors emphasize the role of agreement, 
concensus, and negotiation [Ref. 32, 39, 33]. These authors 
contend that as system design progresses, alternatives are 
proposed and evaluated. The exact definition of a system 
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may net ts as important as the concensus on the inexact 
definition which is attained. An example from Land serves 
to illustrate the importance of satisficing in software 
design: 

. ... the designer has to be aware that building flex- 
ibility into systems can also be expensive, both in 
terms of design effort and operational performance. The 
designer is involved in a trade-off between the extra 
development and operational costs of designing a system 
which is adaptable and flexible — a very general 

system — or of designing a very specific system dedicated 
to the needs existing at the time of implementation, but 
which may be incapable of modification, and may have tc 
be replaced if requirements change. [Ref. 29 : p. 67] 

Satisficing may also involve psychological trade-offs as 
well as technical trade-offs. Madnick and Donovan relate an 
instance where two possible algorithms could have b<=en used. 
The inefficient algorithm was chosen because the designer 
could not stand the suspense of waiting [Ref. 22: p. 491], 

C. SOFTWARE DESIGN IS A WICKED PROBLEH 

Hcrst Rittel has suggested that design problems are 
wicked problems [Ref. 13, 9]. These problems are ill- 

formulated, have confusing information, have many clients 
and decision-makers with conflicting values, and have rami- 
fications in the whole system which are thoroughly 
confusing. Peters and Tripp have suggested that software 
design is a wicked prcblem. They believed that a comparison 
of the attributes and problems associated with software 
design and the characteris tics of wicked problems make it 
apparent that software design is itself a wicked prcblem 
[Ref. 37], A review of the properties of wicked problems 
and their relation tc software design should help tc put 
this notion in perspective. 
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'Wicked pro blems have nc d efini t ive formul a- ion . Any 
time a formulation is made, additional questions can be 
asked and mere information can be requested. Our inability 
to define system requirements completely and unambiguously 
is a symptom of this problem. Current efforts in software 
development seem to be aimed at the symptom rather than the 
problem . 

Several authors raise the possibility that a complete 
set of requirements is impossible, that a state-of-the-art 
system is almost by definition one for which there remains 
some degree of uncertainty at the time requirements are 
prepared. Under these conditions, it is hard to imagine a 
set of "complete' 1 requirements, since the knowledge cf the 
eventual system at that point can only be incomplete 
[Ref. 26 : p. 403]. 

Wicked r rob l sms have no stopp ing rule. Any time a solu- 
tion is formulated, it can be improved or worked on more. 
Cne steps only because one has run out of resouces, 
patience, or something else. Few would argue that there are 
clear stopping rules for software design. (Else why are 
there innumerable examples of cost and schedule overruns?) 

Solutions to wicked pro blems cannot be co rrect or false. 
They can only be goed or bad. This notion can be quite 
controversial amonq computer scientists. Granted, a 
computer system must work properly, especially in life- 
critical cr life-threatening circumstances (hospital equip- 
ment or nuclear reactors, for example). But "work properly" 
has different meanings to different people, or groups of 
people, just as do "correct" or "true". 3 # 



3 Mortimer J. Adler discusses the idea of "truth", an 
idea we judge by, in Six Great Ideas, Macmillan Publishing 
Co., Inc., Sew Ycrk, “ 
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Perhaps "good" and ''bad 1 ' are poor choices as well, yet 
most of us readily acknowledge the differences, when 
presented with "good or bad, for whom?” The distinction 

could be thought of in terms of 'technical success' and 
•psychological success'. Technical success is the degree to 
which the actual performance of the system matches its spec- 
ification, while psychological success is the degree to 

a 

which the end user has confidence in th”» final system 

[Ref. 36]. 

Ancther distinction can be made from the observer's 
point of view of a system: a system exists and is defined 

fcy the perscn(s) observing it. It is as acceptable, perhaps 
even laudable, as the observer perceives it to* be. If a 
system works in the eyes of those who use it, then to these 
users that system is a good one. Conversely, if a system is 
ebserved as not working by those same users, then it is not 
good regardless of any ether attribute it may have. 
[Ref. 33]. 

In so lv ing wicked prob lems t here is no exha us ti ve list 
of a^missable o per at lens . Any conceivable plan, strategy, 
or act is permissable in finding a solution and none can be 
prescribed as mandatory. Anyone in the profession car. see 
that this certainly applies to software design (granted, 
there are at present a finite number of "design methodolo- 
gies", yet each year this number continues to increase). 
The literature is replete with references to design method- 
ologies: object-oriented design, data-oriented design, 

design based on finite-state machines, and so on. 

See Table I for a large, and certainly incomplete, list of 
design methodologies . 

Not only are we faced with many alternatives for a 
design "met hcdolcgy" , but we also are faced with innumerable 
alternatives fer solving the subproblams in the particular 
design case at hand. There may be more than one way in 
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TABLE I 

Eesign Methodologies 



Mnemonic 



F ull Sams of M athodolo gy 



ACM/PCM 
DACES 
D S SAD 

DSSD 

EDM 

GEIS 

HOS 

IBMISD-SEP 

I ESM 

ISAC 

JSC 

NIAM 

SACT 

SABA 

SD 

SA-SD 

SDM 

SEFN 

SREM 

STRADIS 

USE 



Active and Fassive Component Modelling 
Data Oriented Design 

Data Structured Systems Analysis and 
Design 

Data Structured Systems Development 
Evolutionary Design Methodology 
Gradual Evolution of Information Systems 
Higher Order Software 

Adaptation of IBM Federal Systems Division 
Software Engineering Practices 
Information Engineering Specification 
Method 

Information Systems Work and Analysis 
of Changes 

Jackson System Development 
Nijssen's Information Analysis Method 
Structured Analysis & Design Technique 
System ARchitect's Apprentice 
System Developer 

Structured Analysis and Structured Design 
System Development Methodology 
Software Engineering Procedures Notebook 
Software Requirements Engineering Metho- 
dology 

STRuctured Analysis, Design and Implemen- 
tation of Information Systems 
User Software Engineering 



which a target system development process can proceed simply 
because there are alternatie approaches available at the 
time the requirements are written. A decision between these 
alternatives may not be possible [Ref. 26 : p. 403]. 

For eve ry w ick ed prcb l em there is alw ays more than one 
possi ble e xpl a nat ion. The selection of an explanation 
depends on the perspective, or world-view, used. The expla- 
nation also determines the solution to the problem. (For 
example, the high cost of software is often attributed to 
labor-intensive design and programming; poor requirements 
definition is often blamed for software "failures”.) 
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Nc wicked orcblem and no s olutio n to it has a d efinitive 
test . In ether words, any time any test is "successz ully" 
passed it is still possible that the solution will fail in 
some other respect. This characteristic of wicked problems 
is tied very closely to the idea of satisficing. If 
computer systems are built to be flexible, their design must 
be generalized. The aspect of flexibility is gained at the 
expense of efficiency (not that this is badl). So, the 
system "passes" the test for flexibility but is very ineffi- 
cient . 

Each wicke d problem is a " one sho t" operatio n. There is 
no room for trial and error, and there is no possibility for 
experimentation. Many large-scale computer systems have 
this characteristic. In fact, software development is some- 
times compared to building a bridge--once it is built there 
is nc geing back to the beginning ro redesign and rebuild it 
(for any number of reasons) . 

Eve ry wicked pro blem is uniq ue . No two problems are 
exactly alike and no two solutions or strategies leading to 
solution can readily be copied for the next problem. This 
characteristic is very evident in software design. Military 
systems, for example, are certainly unique. Commercial or 
industrial problems are no less unique. Each organization 
has a unique structure, set of goals and objectives, set of 
interactions with the environment, cast of people, and set 
of needs . 4 

The w icked prob lem sol ver has no right to be wron^ — 
he/she is full y responsible for his/ her action . There has 
been a growing skepticism among users regarding the abili- 
ties cf software designers. Users have every reason to 
believe that the software designer "knows" the job. 



♦Note that what is being discussed is the overall 
problem, not a suborcblem. The questions about reuseability 
and software components should be directed ONLY to subpreb- 
lems, for obvious reasons. 
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Clearly, the designer must be aware of many of the factors 
which could affect the design. The designer must also be 
aware cf the effects of design decisions. Allowances will 
and can be made for unusual unforeseen difficulties. But to 
hide behind the "This system meets the specificat ions you 
approved and signed" statement is going (and has gone) too 
far. 

D. CCHMUNICATIONS BETWEEN THE DESIGNER AND THE END OSEB 

Perhaps the single, most widely noted problem area in 
software design is the problem of communication between the 
user and the designer. The recent literature emphasizes the 
need for extensive communications [Ref. 25, 29, 30, 35, 39, 

and 40]. The most common reason given for the problem is 
that users and designers speak with different vocabularies 
and find it difficult to completely understand each ether. 

Much of the literature which cites the need fer closer 
communication is based on empirical and ar.cedotai reports. 
King and Rodriguez [ Bef . 41 ], however, report an assessment 
of participation (and communication) in system development 
in an experimental context. The experiment tested four 
specific hypotheses (see Table II) about participative 
design which were stated in null form. 5 

The experimental results (see table III) indicate that 
participative design makes a difference, especially when 
viewing the "worth of the system". 



5 This cnly means that the 'claim', i.e., "accepted 
wrsdem" in systems design, was set up as the alternative to 
the hypothesis, in accord with traditional - ay pofhesis 
testing. 
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TABLE II 

Hypotheses Tested in the Experiment 



HI: Participation in the development of the system has 

no effect on the user's perception of the worth of the 
system. 

H2: Participation in the development of the system has 

no effect on the amount of use which is made of the 
system when the user is faced with strategic issues for 
which the system was designed to provide support. 

H3: The substantive inputs provided by participants in 

the design process will not be reflected in their usage 
cf the system. 

H4: Tie decision performance of participants in the 

design process will not be different from that 
of non-participants. 







TABLE III 



Results of the Experiment 



Hi: The null hypothesis is rejected. 

This result indicates that managers who are involved in 
the development effort tend to perceive the system to 
be more worthwhile than managers who are merely given a 
pre-designed system to which they had no input. 

H2: Cannot reject the null hypothesis, 

conclude that the use of the system in terns of number 
of queries is not significantly different for design 
participants and non- par ticipants . 

H3: The null hypothesis was rejected. 

it indicates that the substantive inputs provided by the 
participant group in the design and development phase 
of the information system are reflected in their 
actual use of the system. 

H4 : Cannot reject the null hypothesis. 
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As King and Rodriquez put it, the 



. ... experiiient provides some support for "participa- 
tive design theory": (a) The inputs provided by partic- 

ipants appear to have been made use of in their use of 
the system, and (fc) some positive attitudinal impact-- 
in terms of systems "worth" — seems to be achieved 
through participation. [Ref. 41] 

The experiment seems to confirm some deeply held convic- 
tions that participation in, and responsibility for, design 
implementation can result in elimination or reduction of 
communicaticn problems [Ref. 29: p. 65]. 

There may be seme reason to believe that the real 
problem with communication is not whether it takes place but 
whether tie media of communication is appropriate. The fact 
that the designer has produced a comprehensive specification 
and that the user has ’signed off’ the specification after 
due study, is not a guarantee that the designer has under- 
stood the user's needs, or the user the designer's specifi- 
cation [Eef. 29 : p. 65]. Stucki has suggested that charts, 
graphics, color pictures, and other aids should be used to 
enhance communications between users and designers; verbal 
descriptions alcne are just as inadequate for describing 
software as they are for an architect building a house. 
[Ref. 30]. So, although communications may be a significant 
problem, its form may be equally as important. 

E. SOFTWARE DESIGN IS LEARNING 

Software design is learning, just ask any experienced 
program manager. They want someone with design experience 
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to head the design team [Bef. 46], Without explicitly 
acknowledging it, these managers place value in the experi- 
ence learned from previous work. This "learning from 

doing" also takes place during the design of a system: 

The reason for the discovery aspects of software design 
is the designer's learning curve. As the system is 

studied, analyzed, and a design formulated, certain 
features are recognized as needing attention while 
others are overlooked. As it becomes apparent which 
features are lacking, priorities shift. [Ref. 37] 

If we accept that learning is an element of design, just 
how important is learning to design? In an experiment, 

Alavi and Henderson [Ref. 55] evaluated two strategies for 

systems development: evolutionary and traditional. By 

their definition, the evolutionary strategy emphasized the 
role of individual learning. They reported that the find- 
ings support the hypothesis that an evolutionary implementa- 
tion strategy is more effective than a traditional strategy 
[Ref. 55]. 

They try to explain their findings this way: 



A model which offers an explanation for the findings is 
Kolfc's experimental learning model [see Figure 3 . 1 J . 
Kolb suagests that for a learner to be effective he/sne 
must have the ability to engage in four types of activi- 
ties: (1) involvement in new, concrete experiences, (2) 

observation and reflection of these experiences, (3) 
creation cf concepts that inteqrate these observations 
into theories, and (4) usage cf these theories to make 
decisions and solve problems. . . . The evolutionary 

strategy maps directly with a starting point at concrete 
experiences. In contrast, the traditional approach 
began with the development of a theory. ... An expla- 
nation cf the findings may rest in the support that the 
evolutionary strategy had for the learning process. 
[Ref. 55] 



This model has some important implications for soft- 
ware design. For example, the perspective or world-view 
that the designers (and users) bring to a project become 
important (after all, we are starting from concrete 
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Figure 3.1 Kolb* s Learning Cycle Model. 

experiences). Greenspan and others believe that the ability 
to efficiently design appropriate computer systems and 
enable them to evolve over their lifetime depends on the 
extent tc which real world knowledge can be captured 
[Bef. 43]. Wasserman [Bef. 35] takes the thought further by 
suggesting that members of the different groups concerned 
with design perceive the function of an information system 
differently. Misunderstandings of objectives can and do 
occur, many times leading tc project failure. 
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Land [Bef. 29] also states that there are diffsrenx 
ideologies and perspectives among the different interests 
involved in a systems study. Land suggests that managers 
meet this challenge by setting up a design team which 

contains representatives of all the major interest groups, 
making it possible for the different ideologies and perspec- 
tives of the participants to be made explicit, and for the 

different members of the group to learn from each o thers 

dif fere nt v i ew o o in t s [Ref. 29]. 

Hew might xhe participation of users in the system 

design enhance or promote learning and real-world knowledge? 
Robey [Ref. 42] conducted an experiment that explored a 
model of constructive, conflict in the MIS development 
process. * His mcdel (presented in Figure 3.2) is described 
here : 

User par tic ipation should lead to co nflicts , which 
should* Then T5a ~ satisf actorily resolv ed . However, 
conflict and its resolution are more IXlcely to occur 
whan users can exercise their i nf l uence in the develop- 
ment process. Conflict itself “foes not lead to its 
resolution: rather the increase in conflict makes reolu- 
ticn more difficult. It is only through parxicipat ion 
and influence that conflict can be successfully resolved 
in this mcdel. [Ref. 42] 

There is other research which supports Robey's 

"constructive conflict". Boland [Bef. 54] compared two 
different processes of interaction in system design: 

1. traditional--the designer conducts a traditional 

interview of the user 

2. alternat ive-- the designer and 

present mutual suggestions, 
suggestions. 

His results are significant: 

1. The alternative process produced higher quality 

designs with important i mp lament axi on advantages. 



user share ideas, 
and critique their 
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Figure 3.2 A Constructive Conflict Model for User Involvement. 



2. The two processes produced designs which used 

different organizational control strategies. 

3. Different processes may help to define different 
problems and thereby produce different, but squally 
rational, solutions. (Bef. 54] 

Boland likens the problem solving process to a dance during 
which the designer punctuates his interaction with the user 
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in a serias of te achin g , sugges t inq , and cri tiquin g. 
Eoland asks us to accept the notion cf learning and the 
importance cf real wcrld knowledge: 

Let us accept that the viewpoint and implicit models 
held ty designers will color their collection and inter- 
pretation cf data about the needs of the organization 
they are designing for. This study suggests that under- 
standing how that viewpoint builds a coherent design 
statement requires an understanding cf how the designer 
interacts and exhanges information with his client. The 
interaction protocols may then be seen as mediating the 
process cf completing the designer's "point of view" 
(creating the design statement). [Hef. 54: p. 896] 

Robey's experiment lends support to Boland's findings: 
"It appears that participation does lead to perceived influ- 
ence in . . . system development" [Ref. 42], Robey's find- 
ings suggest that influence is used constructively to 
resolve conflict and that users learn how to exert influ- 
ence towards conflict resolution as well as conflict genera- 
tion as the development process proceeds [Hef. 42 : p. 82]. 

As we have seen, there is support that learning, argu- 
mentation, and a designer's world-view are important 
elements in software design. 

F. SOFTWARE DESIGN HAS AN ORGANIZATIONAL CONTEXT 

At first glance, the casual reader is apt to say "You 
are stating the obvious." Yet much of the current work in 
software design ignores the obvious. Land provides seme 
evidence for this: 

1. Users are uncertain about the affect the final system 
will have on their individual roles in the organiza- 
tion and on them personally. 



6 Ccmpare Boland's "dance" and Robey's "constructive 
conflict" fer software design to Rittel's "argumentation" in 
design (Charter II) . 
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The observation that the user operates within formal 
systems and that the formal procedure cf the existing 
systems have teen overtaken by less formal (but often 
mere effective) unauthorized procedures. 

3. The fact that those who are involved in the analysis 
prccess--DP specialists and users — are often not 
aware of strategic decisions made by senior manage- 
ment which could have an important bearing on the 
workability of the system. 

4. New systems almost certainly include innovations; 
users and ana lyst/de signers cannot predict managers' 
responses to innovations. Conjectures about people's 
behavior are no substitute for knowledge, and in 
innovation, such knowledge is not ordinarily avail- 
able. [Ref. 29; p. 64] 

Although Land cited these points as reasons for communi- 
cations problems, they can equally serve as indictments 
against current software design. That is, org an izat icnal 
aspects cf software design are often ignored. 

Wasserman points out that organizations and computing 
environments are highly dynamic and that information systems 
must be designed for a changing organization [Ref. 35]. 
Chafin states that as computer systems become more deeply 
involved in the operations of organizations, they have 
larger social effects on these organizations. A new 
computer system may change the organization structure, the 
power structure, or the overall information flow structure 
in an organization [Ref. 40]. 
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Zmud and Cox recognized the organizational aspects of 
software design in their discussion of a "change” approach 
to design and implementation: 



The change approach to MIS implementation strives to 
create an environment in which change will be accepted 
through the active involvement of affected organiza- 
tional members, an intensive educational program, and, 
most importantly, the assigning of project responsi- 
bility to the MIS user. Additionally, a sense of mutual 
trust and committment must develop between participants 
so that a free exchange of beliefs and opinions is 
possible. [Ref. 53 : p. 37] 



Zmud and Cox make no reference to wicked problems, yet 
their change process is reccmmended when (1) the organiza- 
tional activity involved is ill-defined, (2) the MIS must 
interface with other organizational systems, and (3) 

substantial organizational change is expected. Compare 
these characteristics to Horst Rittel's characteristics of 
wicked problems (Chapter II). 

Although there are several articles and references to 
organizational aspects of software design, two authors stand 
cut. Kling and Scacchi have written two extensive articles, 
[Ref. 59 and 60], which stress the need for an awareness of 
and attention to organizational and social aspects of system 
design. Their latest work (Ref. 60], develops a family of 
models (called web models) which they believe helps tc "make 
tetter predictions of the outcomes of using socially complex 
computing developments". These models are contrasted to 
' discrete-entity '--rational and traditional — models. Their 

work attempts to abstract a set of principles, 
characteristic of web models, from analyses published in the 
literature. 
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Kling and Scacchi stress the importance of perspective 
in the “social analyses of computing''. They identify six 
perspectives, four of which predominate: 

1. Formal-rational 

2. Structural 

3. Interact ionist 

4. Political 

Their point in discussing these perspectives is that each 
“casts a different light" on the significant aspects of the 
design problem . 7 

Further discussion of the work of Kling and Scacchi is 
beyond the scope of this work. The point to be made of 
their work is that software design is conducted in an orga- 
nizational framework: 



In contrast tc the discrete-entity 
simplicity by ignoring the social 
developments, web models make e 
conections between a focal technolo 
political contexts. [Ref. 60 : p. 



models, which gain 
context of computing 
xplicit the salient 
and its social and 
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G. SOFTWARE DESIGH IS EVOLUTIONARY 



Much of the current 
constrained by a model p 
model. Ten Gilb aptly sum 
ware prof essionals : 



practice 
opularly 
s up the 



in software 
termed the 
attitudes of 



design is 
watsrfa 11' 
most soft- 



It seems that they recognize, as yet, only one tyoa of 
life cycle. In particular, they seem to be speaking of 
a revolutionary life cycle (like the birth or a human) 
as opposed to a mere evolutionary life cycle [such as 
the development of the human species). [Ref. 34 j 



7 Klmg and Scacchi present an extensive discussion of 
the social dynamics cf system design in [Ref. 59]. Their 
discussion is based cn tne four perspectives mentioned as 
well as two others: human relations and class politics. 
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ether authors also complain about the current life cycle 
model. Brittan is concerned that the serial definition of 
the project development cycle, known as the linear strategy, 
embodies one fundamental concept: that an activity follows 

logically from its predecessor so that each stage is 
complete before the next begins [Ref. 36]. McCracken and 

Jackscn seem to be the most critical of the current life 
cycle model. They believe rhat any form of life-cycle is a 
project management structure imposed on system development. 
Furthermore, they point out that the current life cycle 
modal is either a very much simplified model (which is 
worthless) or unrealistic [Ref. 27]. Podolsky [Ref. 24] 
argues that the current model (which he terms 'Classic 
Development') is "very, very good" when it is successful, 
but than when it fails, "it's horrid". He attributes the 
success and failure of Classic Development to the type of 
problem which will be solved: classic development is good 

for well-defined, highly structured, change-resist ant prob- 
lems; it fails when presented with an ill-defined problem, 
changing participants, and changing requirements. 

Zvegintzov [Ref. 57] has twe objections to the current life 
cycle model. First, it does not portray a systems life, 
only the creation, development, or youth of a system. It 
does net include adulthood and is vague about operation and 
maintenance. Second, it is not a cycle, it portrays a 
linear path and does not, as a cycle must, return tc its 
beginning [Ref. 57], Gladden even goes so far to say that 
the software life cycle may be harmful to the software 
profession. See Figure 3.3 for Gladden's representation. 

These arguments, and others, begin tc raise a question 
about the validity of the linear strategy. The linear 
strategy places a great deal of reliance on the studies and 
efforts made in the earlier 'stages' of software develop- 
ment. Yet this strategy ignores the fundamental aspects of 
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Figure 3.3 Typical Life Cycle Hepresentation. 



design described in Chapter II. Brittan places this 
predicament in perspective: 



In a majority cf cases, particularly when the organiza- 
tion responsible for designing and implementing the 
system has experience of similar systems and when the 
users are clear about what tney want, the linear 
strategy is pefectly satisfactory and produces gcod 
regults. Too often, a project starts on the linear 
strategy hut the initial requirement is vague, over- 
ambiticus or fails to meet the real need: in fact the 

requirement is still fluid. The project then proceeds 
in a series of short locps as the requirement solidi- 
fies. . . . [Hef. 36] 



Now it becomes clear why Gladden's representation in Figure 
3.3 appears as it does. To make up for the reality of soft- 
ware design, the practice is to use a 'loopy linear' 
strategy. That is, to proceed in a series of relatively 
haphazard and short-term locps. Again from Brittan: 



Some loops are inevitable. One of the symptoms of 
excessive loopiness is a feeling of antipathy between 
the different groups associated with the orcject, 
particularly if they are geographically dispersed (the 
we/they syndrome) ;tne svstsm desianers wirl crumble 
about users never knowing "what they'want and users will 
be annoyed by the apparent lack of good project manage- 
ment as the system overruns its budget in both time and 
cost. [Ref. 36] 



Brittan gives other reasons why the linear strategy is poor: 

1. when analysts refine the requirements of a system, 
their investigations and studies frequently threw up 
problems which were not suspected at the outset. 

2. the linear strategy can only be based on studies and 
investigation s made by analysts; users, who determine 
the success of the system, are not usually adept at 
the conjecture and extrapolation needed to understand 
these studies. 

Land [Ref. 29], Brooks [Ref. 46], Podolsky [Ref. 24], Zave 
[Ref.. 32], and Lehman [Ref. 47], to name a few, have all 
argued that a system will require substantial, continuing 
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changes after the client begins to use the system. We tend 
to relegate this phenomenon to * Maintenance' . But this 

isn't enough. Consider this comment by Land: 



The conventional model of the systems life cycle assumes 
that an analysis and feasibility stage precedes the 
detailed design stage and that this will be followed by 
a specificiat ion ana agreement of the specification for 
the system. At that point the design of the system is 
often frozen. For a typical information system the 
staaes precedina the design freeze rake between 20? and 
35? of the total time required for the develoment of the 
system. For between 65? and 80? of this time the design 
of the system is not to be modified, even though tne 
"world" is changing all the time. In practice, even a 
frozen design gets modified if the system is seen to be 
becoming irrelevant to real requirements. Further, 
inconsistencies in design are discovered during the 
construction phase as a result of "systems queries". 
[Hef. 29 : p. 68] 



Software design, no matter how hard we try otherwise, is 
simply net linear. The literature clearly supports an 
evolutionary strategy, yet our practice has not recognized 
this . 



H. SUMHABY 

The preceeding discussion shows that there is support in 
the literature for reassessing our view of software design. 
Software design is symmetrical, but we currently do little 
to recognize that symmetry. Software design is satisficing, 
yet there is constant emphasis on optimization, often for 
its own sake and forsaking approaches that enhance the 
useability or quality of the software. Perhaps, without 
consciously noting it, we are also concerned with the "test" 
design and dooming the project to mediocrity, at best, and 
perhaps catastrophe. 

Software design, especially for large-scale systems, is 
certainly a "wicked problem." All the evidence is there; it 
only remains to acknowledge that fact. We are well aware 
that communications between the designer and user are 
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all- important. Yet, we have not really given much thought 
to the medium of exchange. Software design is a learning 
experience. Designers learn that projects are more complex 
than expected and users learn never to trust designers. 
This may he a harsh critique, but the point is well illus- 
trated: all parties gain something from the experience of 

software design. Let us recognize the worth of this. 

The organizational context of software design has long 
been ignored, particularly in military systems. Wa must not 
forget that the computers are to help the people in a s yste m 
to £erfcrm wel l , not to control the people as a part of the 
system. Finally, we are beginning to recognize that soft- 
ware design is evolutionary. There really is no "end" to a 
project, simply a restatement of the goals originally iden- 
tified. 

although seven characteristics have been stated and 
discussed, their interdependencies are obvious. None of 
these characteristics is mutually exclusive of another. 
Rather, each builds on the ether. Although there are innum- 
erable implications in that statement, the remainder of this 
work will examine one approach which may help us to consider 
the sever characteristics of design in software design. 
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I?. THE SO FTW ARE PRO TOTYP E 



A. IHTBCDUCTION 

For the last 35 years, systems software development has 
teen based on the sc-called 'system development cycle.' As 
shown in the last chapter , there are several arguments 
against such a cycle. Perhaps the most railing argument 
lies in cur process controls. Several authors [Ref. 61 , 
62] have pointed out that in response to uncertainty and 
increased complexity, there is a tendency to define and 
structure (and increase!) management controls. 

Correspondingly, precise requirements definitions have been 
emphasized. Berrisfcrd and Wetherbe [Ref. 61] believe that 
there is a major conceptual flaw in the traditional view of 
systems development. This is that system design assumes 
that management knows what information is needed and it is 
difficult, if net unrealistic, to ask managers to define 
their information requirements on paper. 

Hew dc software designers cope with this problem? Rich 
and Haters [Ref. 63] have explored this question and 
theorize that software designers cope with complex design 
problems by using several mental tools, one of which 
involves simplifying assumptions. The use of simplifying 
assumptions is both necessary and commonly used when 
constructing large and complex systems: 

Given a complex programming problem, expert programmers 
typically choose simplifying assumptions which, thouah 
false, allow them to arrive rapidly at a program which 
addresses the important features of the problem without 
beina distracted by all of its details. The simplifying 
assumptions are then incrementally detracted with corre- 
sponding modifications to the initial program. Often 
the main questions can be answered using only the 
initial program. [Ref. 63 : p. 150] 
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This use' of simplifying assumptions in software design 
is very much like the idea cf the tentative solution, . which 
was introduced in Chapter II. Such a tentative solution is 
only a simplified system. Earl [Ref. 64] calls these 
simplified systems prototypes. Carrying this one step 
farther, Naumann and Jenkins define a prototype system as 
"a system that captures the essent ial fea tures of a later 
system. " [Bef. 62]. The sections which follow will 

describe the prototype process, the role of prototypes as 

models, the ways in which prototypes are used and concludes 

by showing how the set of seven desing elements are 

supported by software prototypes. 

B. THE PHOTOTYPE PROCESS 

The terms prot o typ e and p rototype systems have become 
rather common lately, found in both the management litera- 
ture (Harvard Business Review, for example) and the software 
engineering literature (proceedings of conferences and work- 
shops especially). Although the term pro toty pe has become 
standard, early descriptions of the process were called 
"heuristic development" and "iterative enhancement" 

[Ref. 61, 65]. 

Regardless of how each of us may use the term, there is 
general agreement that the main purpose of prototype systems 
is exploration and experimentation; "the aim of the early 
prototype is to learn, to find out, to discover." [Ref. 68, 
64, 66]. In keeping with their purpose, prototypes are 

relatively inexpensive, flexible, and simplified systems. 
Bally, Brittan, and Wagner describe the prototype process: 

In the prototype strategy, an initial and usually highly 
simplified prototype verson of the system is designed, 
implemented, tested and brought into operation. Based 
on the experience gained in xhe operation of the first 
prototype, a revised requirment is established, and a 
second prototype designed and implemented. The cycle is 
repeated as often as is necessary to achieve a 
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satisfactory operational system. bearing in mind the 
possibly escalating cost of each subsequent cycle; it 
may welu be that only one prototype is necessary before 
producing the final system, [fief. 68: p. 23] 

From this description, four steps are evident [fief. 62]: 

1. Identify the user's basic information requirements. 

2. Develop a working prototype. 

3. Implement and use the prototype. 

4. Revise and enhance the prototype. 

Figure 4.1 illustrates the prototype process. 

A prototype system must be implemented quickly, perhaps 
in hours or days, certainly no more than two or three weeks. 
The advantage here is in the user-designer interactions: 
the user is given a working system to operate and criticize, 
the designer receives responses based on the user's experi- 
ences. The quick response of the designer guarantees that 
the first prototype will be incomplete. This aspect is 
important: there is an explicit understanding between the 

user and designer that the system will be incomplete, that 
a prototype is meant to be modified, expanded, supplemented, 
cr supplanted [Ref. 62]. 

C. P50TCTYPES AS MODELS 

Many authors consider prototypes to be models [Ref. 64, 
82, 69], As models, prototypes reduce risk and test alter- 
native designs through live operation. [Ref- 64]. 

Three aspects of prototypes as models are important. 
First, models are abstract: 

The critical skill cf system design is . . . claimed tc 
be explicaticn of the implicit models in managers' 
minds, of their decision-makina processes and views cf 
their organisation and environment. [Ref. 64 : p. 163] 
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Figure 4.1 The Prototype Model. 

Second, managers prefer simple models at first. As they 
begin to understand the models, they become involved with 
the design and implementation to build more realistic 
systems. [Ref. 64]. 

Third, a prototype is subject to modelling effects. 
That is, as a model, the prototype is only a limited version 
of the final system. So, a prototype is one kind of scale 
mod el , accurate in some ways, inaccurate in others 
[Ref. 69]. 
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D 



STRATEGIES TO PRODUCE PROTOTYPES 



Three strategies are generally recognized for producing 
prototypes, 1) methodologies (in current use) , 2) executable 
specifications (state-of-the-art and research issues), and 
3) automatic programming (a research topic) . 

1 • 2 he 'Methodol ogy » S trategy 

There are three basic methodologies which are used 
to produce software prototypes. First, in screen and report 
formatting, the designer produces a sat of user interfaces 
which will be similar to the final system. Second, in 
partial ard incomplete implementation, the designer and user 
identify cnly a s ubset of the total problem. Third, for 
selective implementation, the designer develops components 
of tte final system and then integrate the components. 
[Ref. 71] 

2 • Executable Sp ecifi ca tion s 

The executable specification, the second technique 
for prototyping, is a current 'hot' topic in the computer 
science literature. Davis [Ref. 72] describes a software 
tool, the Feature Simulator, which "executes" formally 
written requirements specifications for real-time systems. 
Feather [Ref. 73] proposes a methodology for developing 
prototypes from specifications based on the transformation 
of "specification constructs" into an implementation. 
Perhaps the most ambitious work on executable specif icaticns 
is that reported by Cohen and others. They believe that "a 
prototype serves to mitigate both imperfect communication 
and lack of forsight (sic)." [Ref. 74] 

Ihe solution Cohen and others have adopted separates 
the imperfect communication and lack of foresight issues by 
having a formal specification language which unambigicusly 
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describes systems, and a separate tool (symbolic execution 
system) which helps the reader to understand any particular 
specification. This tool can be used by the specification 
writer tc validate the specification and by the implementor 
(or buyer) to understand what exactly has been specified 
(i.e., hew the pieces interact). "Given the specification 
and the tool, a prototype will not be needed." That is, if 
the designers can completely specify the requirements and 
they then use the symbolic execution system, Cohen and 
others believe that it is no longer useful to develop a 
prototype . 

Eut consider the following comment by Taylor and 
Standish : 



. . . . having a precise specificat ion language is of no 

help, since the user really doesn't know what statements 
to make in such a language — that is, he can't articu- 
late his needs if he doesn't know what they are recrard- 
less of whether or not there is a precise language for 
stating them. [ Sef . 78 : p. 160] 

Executable specifications clearly are controversial, 
especially whan thay concern prototypes. Whether such a 
technique gains prominence will depend on advances in soft- 
ware engineering tools. 

3 • Automatic Pro grammi ng 

Automatic programming is probably farther away, 
technically, than the executable specification. Automatic 
programming can be thought of as programs that help people 
write programs. The general goal of automatic programming 
is tc allow the software designer to think of the problem 
abstractly, in a way which is natural and comfortable. 
Automatic programming systems are characterized by specifi- 
cation methods (formal, 'by example', or natural language), 
the target language (the language in which the system writes 
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the finished program) , the problem area (area of intended 
application) , and the method of operation (theorem-proving, 
program transformation, knowledge-engineering, or tradi- 
tional problem solving) [Refi 100]. One advantage of auto- 
matic programming is that it could allow for more 
informality than an executable specification language 
[Ref. 70]. 

E. OSES CF PROTOTYPES 

Generally, there are three uses of prototypes, 1) to 
clarify user requirements, 2) to verify the feasibility of a 
design, and 3) to create a final system. [Ref. 75]. 

1 . To Cla rify the U ser 1 s Requir e ments 

Ey far, the most popular use of prototypes is to 
clarify the user's requirements. McCracken [Ref. 67] 
believes that traditional written specifications do not 
bridge the communications gap between the designer and the 
user. He states that prototypes en courage users to change 
their minds about what they want, until the system is 
use ful. 

To highlight the problems encountered in require- 
ments documentation. Mason and Carey [Ref. 76] make a 
distinction among three types of documentation: 

1. A textual list of requirements (the most commonly 
used) 

2. An interpretive model (gaining in popularity, espe- 
cially in military systems) 

3. A working model — a prototype 

The textual list, the traditional method of 
describing requirements, has a distinct disadvantage. There 
is a psychological distance between a textual list and what 
the users will eventually receive. A lengthy (often boring) 
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document does not easily convey a realistic sense of how the 
system will operate and suit the user's needs (Ref. 76-]. 

Interpretive models include SADT and USE. These 
models use top-down decomposition to manage the complexity 
of large systems. The more detailed these tools are (or 
become), the more specialized the language used. This pres- 
ents a significant learning burden to the user [Ref. 76]. 

Prototypes, cn the ether hand, present a more real- 
istic view of the system to the users. The users can easily 
relate their experience with the prototype to their 
requirements. 

2 • To Ver ify the F eas i bili ty of Design 

When prototypes are used to verify the feasibility 
of a design, the designers and users are evaluating the 
internal design of the software [Ref. 75]. After the proto- 
type is developed, several aspects of the design could be 
evaluated: the prototype could be used to implement and 

evaluate certain design decisions; the prototype could be 
used to develop and test a production system; the efficiency 
of the prototype could be examined; or the prototype could 
be developed on one machine, and the final system imple- 
mented cn the target (or production) machine, when it 

becomes available. 

3 . Tc Crea t e the Final Syste m 

Prototypes may be used to create the final system. 
This means that part or all of the final version of the 
prototype may beccme part of the production system 

[Ref- 75]- Examples of this technique might include data- 
base managenment system (DBMS) applications. For example, 
once created, the prototype might remain unchanged espe- 
cially if the system efficiency is satisfactory. On the 
other hand, critical (or perhaps all) of the system would be 
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recoded for efficiency, either in the DBMS language, in a 
host language, or in assembly language. 

P. FBOTCTYPES ADDRESS THE ESSENTIAL DESIGN ELEMENTS 

1 • Prot otypin g is a Sy mmetr i cal and Adaptabl e Pr ocess 

Prototypes explicitly address the symmetry and adap- 
tation necessary in software design. Naumann and Jenkins 
[Ref. 62] believe that prototypes provide an appropriate 
response to changes in the development process (problems to 
solve and available resources) as well as to changes in the 
environment. Bally, Brittan, and flagner state that the 
prototype strategy is an admission of failure, an admission 
that there will be circumstances when we will be unable to 
develop the right system on the first attempt [Ref. 68]. 
Earl’s comment perhaps best expresses the overall idea of 
symmetry and adaptation: 

The prototype system . . . allows . . . design by 

disc overy as much as bv prediction, where the unexpected 
results' may be as significant for design as the 
expected, (emphasis added) [ Sef . 64 : p. 166]. 

2. Prot oty ping ’Tames ♦ the fl ick ed Proble m 

In Chapter II wicked problems were described as 
problems where the information is confusing, where there are 
many clients with conflicting values, and where the ramifi- 
cations in the whole system are thorougly confusing. 
Compare those characteristics to the experiences of Asnar 
and King: 



. . . . the prototype approach works when users do not 

knew their specific requirements, [where] the effective- 
ness of any on particular approach cannot be easily 
assessed without real-life experience, . . . [where] 

the system will be an integral part of the day-to-day 
activities of the users. . . . [Hef. 79 : p. 30] 



57 



Developing prototypes does more than recognize 
wicked problems. The designers and users of prototypes 
explicitly acknowledge such things as: 

1. Wicked problems have no definitive solution — as Eally 
and others have stated, prototypes are an admission 
that more questions can be always asked and more 
information can be requested. 

2. Every formulation of the wicked problem corresponds 
to the formulation of the solution (and vice 
versa)-- there is an explicit understanding between 
the desinger and user about basic assumptions that 
will be made when designing a prototype, especially 
the first version; the protcype strategy is designed 
tc ccpe with a fluid situation and fuzzy requirements 
[Bef . 68 ]. 

3. Wicked problems have no stopping rule — designers and 
users realize that prototypes may be continually 
modified cr refined until some external limit (time, 
resources, production need, user satisfaction, etc.) 
is reached. 

4. Solutions to wicked problems cannot be correct or 
false. They can only be good or bad — prototyping 
explicitly recognizes the notions of "technically" 
correct and "psychologically" correct. Users contin- 
ually ask for refinements until they become satisfied 
(i.e., where the system is technically and psycho- 
logically correct) . 

5. In solving wicked problems there is no exhaustive 

list of admissable operations — prototypes allow 

designers and users the freedom to explore and exper- 
iment . 

6. No wicked problem and no solution to it has a defini- 
tive test — designers and users become quickly aware 
that prototypes clearly identify tradeoffs. The 
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prototype may be flexible and sacrifice (i.e., "fail” 
the test for) efficiency. 

3* Sof twa re Pro totypin g i s Sat is ficin g 

Recall from Chapter II Simon's argument that people 
accept alternatives which are good enough, not because they 
want to, tut because they have no choice. In Chapter III 
evidence was presented which clearly shows that software 
designers constantly balance trade-offs and are forced to 
accept satisfactory alternatives, rather than an optimal 
alternative. 

The process of developing a prototype explicitly 
deals with satisficing by recognizing the interaction among 
the user, designer, and system. Conflicting goals and 
priorities are inevitable. Negotiation between the designer 
and user will lead tc a satisfactory system. 

In the prototyping process, the designer constructs 
successive versions of the system, compromising and 
resolving conflicts between the context (than is, user needs 
and desires) and the form, as constrained by technology and 
economics [Bef. 62 : p. 37]. 

4 . Prototyping is Comm unic ating 

The prototype facilitates communication between the 
designer and the user; The basic model of the prctcype 
process shows that communication is a necessary element of 
the process. Without communication there is no prototype. 
Mason and Cary £ Ref . 76] believe that prototyping overcomes 
the fundamental problems of communication between users and 
designers. Naumanc and Jenkins [Bef. 62] emphasize the 
roles participants have and believe that prototyping 
stresses the interactions between the user and the designer. 
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FarticipatioE in software design can be painful 
[Ref. 64 ] r yet 

Users play more active roles in prototyping than is 
possible with traditional development methods. Users 
set the development pace by the time they spend using 
and evaluating the prototype. They decide when the 
c^cle cf evaluation and refinement ends. [Ref. 62 : p. 

The prototype approach exploits the interaction 
between the designer and user. Contrast this with the care- 
fully monitored interaction in the traditional approach. 

5. The Sof tware Prototype is a L earning Aid 

Several authcrs [Ref. 64, 68, 66] agree that the 

very purpose of the prototype is to allow the user tc learn 
about the system; experience with the system is the most 
valuable product. When prototyping, both designers and 
users learn, developing a system which is more realistic in 
its economic purpose, organizational context, and technical 
performance [Ref. 64 : p. 166]. 

Earl [Ref. 64] believes that prototype systems 
permit action learning and that there are few other vehicles 
available fcr live and flexible organizational development. 
As a vehicle for learning. 



. . . . the protcype model is the most effective repre- 
sentation possible since it enables evaluation of the 
proposed desian in con text. The prototype model is the 
representation tEat an'ETcipates evaluation of the design 
in its operating environment. [Ref. 62 ; p. 33] 
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6 • The Prototype Proc esss Acco u n ts for Org anizat iona l 
I ss ues 

As pointed out in Chapter III, the organizaitcnal 
context is an important consideration in systems and soft- 
ware design. Informal organizational structures and the 
sub-elements of organizations play large roles in the 
success cr failure of a system. As an experiment, the 
prototype provides an opportunity to test the impact of a 
system and experiment on the organization's interfaces, at 
least reducing the risk of a nonviable system and also 
providing opportunities for introducing and monitoring job 
satisfaction improvements, organization development, and the 
like [Ref. 64: p. 164], Earl believes that prototypes are 
relevant to organizations because of individual differences 
among people in the organization: 



. . . . the prototype methodology mav be relevant, for 

different values, perceptions and perspectives do exist 
among different interest groups, bur the different 
implications and impact of a system design mav net be 
appreciated unrii it is implemented; indeed'all the 
options may not be apparenr.' With a working prototype 
system design values may be explicated and stakeholders 
counter the technical thrust of rhe specialists. . 

[Ref. 64 : p. 165] 



To say that prototyping "solves" the organizational 
issues in software design is, however, going too far. 
Prototyping deals expl icitl y with the issues, yet requires 
quite a bit of "orchestration". The management of the 
process is not without political consequences [Bef. 66], 

Hew do we measure the worth of a prototype as it 
contributes to our design of software? Earl answers this 

guestion with the following statement: 

Possibly the most valuable contribution of the prototype 
methodology is to fester a climate of system apprecia- 
tion, user creativity and experimentation, intelligent 
use and organisational learning. [Bef. 64 : p. 166] 
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7. 



The Prot otyp e Proc ess is Evolutionary 

That the process of protoyping is incremental and 
evolutionary shold come as no surprise. The important point 
is that the prototype process, again, explicitly deals with 
the issue. Software design has been shown to be evolu- 
tionary, yet traditional software development is unable to 
deal with it. Naumann and Jenkins [Ref. 62] state, as a 
•principle', that "[ p ]rot otyping represents and parallels 
the dynamic process of growth, change, and evolution 
existing in any living system." 

A survey of the literature reveals an interesting 
pattern among the models for prototyping. Although most 
authors will agree that the traditional life cycle is not 
evolutionary, with the exception of Naumann and Jenkins 
[Ref. 62], (see also figure 4.1) Basili [Ref. 65], Bally and 
ethers [Hef. 68], Earl [Ref. 64], Mason and Carey [Ref. 76], 
and Zvegintzov [Ref. 57] all attempt tc force a c vc lie 
structure on software development. 

Perhaps a review of evolution is in order. When 
some thing (animal, erganizaiton, or design) evolves, it 
begins simply (a few cells, a few people, a few details and 
many simplifying assumptions) and grows in complexity, often 
changing remarkably from ins humble beginnings. This 

process is clearly net cyclic. Rather, a better image is 
the spiral, much like the spiral coil of the shell of the 
Nautilus, growing in size yet maintaining the essential 
nature it began with. 

Figure 4.2 illustrates the evolutionary nature of 
prototypes. Each "chamber" can be considered to be a single 
prototype, the wall of the "chamber" denoting the point of 
refinement and enhancement. The only restrictions on the 
number of "chambers" (prototypes) are in the environment 
(exhausted resources, end of time, too complex or unwieldy, 
and sc on) . 
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Figure 4.2 Evolution of Prototypes. 

G. SUMMAEY AND INTERMEDIATE CONCLUSIONS 

This chapter has explored the multi-faceted aspect of 
the software prototype: the process, its role as a model, 

construction strategies, and uses. The chapter concludes 
with a persuasive argument that prototypes explicitly 
support the seven design elements. 



63 



Several conclusions can be stated at this time. First, 
the current practice cf software engineering only recognizes 
a few cf the design elements described in Chapter II. 
Software design completely ignores the fact than these 
elements are interrelated and mutually dependent. The 
traditional method of software development only worsens the 
problem . 

Second, the prototype approach to software design and 
development naturally supports the set of design elements. 
For example, the prototype approach encourages, requires, 
and exploits the interaction and communication between the 
user and designer. Ey making this explicit, prototypes will 
lead to a better design. 

Third, developing better systems, delivering them on 
time and within budgets are in our best interests. Ihe 
prototype approach will allow software engineers and 
designers to achieve these goals. 

The next chapter briefly describes software engineering 
environments and how such an environment could and should 
support software prototyping. 
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?. THE SOF TWAR E 5 HGIBE EBIN G ENVIRONMENT 



A. INTRODUCTION 

Most authors agree that prototyping has become possible 
through recent developments in computer technology [Ref. 61, 
62]. Collectively, this technology is called the software 
engineering environment (SE 2 ) [Hef. 83], the programming 
support environment [Ref. 107, 105], or the software devel- 
opment environment [ Ref. 84 ]. 

There are as many definitions for, as there are 
references to, a software engineering environment. The 
definition offered by Hausen and Muellerburg seems tc be the 
most satisfying: 

[A Software Engineering Environment is ] an instrumented 
and organized software development laboratory where many 
people cooperate with each other in a fully organized 
worxina orocess, in the design,, construction, examina- 
tion, tuning and maintenance or software. [Ref. 83 : p. 

1 4 7 ] 1 l 

Generally speaking, the literature cites two approaches 
to computer-aided design for software development: 1) the 

SE 2 is a systematic approach, and 2) toolboxes or toolkits 
which support specific software development activities 
[Ref- 85]. The UNIX development environment is an excellent 
example of the toolkit approach [Ref. 86]. The facilities 
of UNIX may be thought of as a "tool kit" from which the 
developer can select tools that are appropriate for a 
specific task. Detailed discussions of the UNIX environment 
and available tools can be found in [Ref. 87 , 88]. 

The toolkit approach, however, has been criticized 
beca use : 
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1. Tools are not organized to support specific software 
development methodologies; 

2. Teels dc not capture management or control data for 
software development; and, 

3. Individual tools are largely uncoordinated [Ref. 89]. 
Lauber has reviewed 11 tool systems in practical use and 
finds that only two systems (PSL/PSA and PDL) are in wide 
use. 8 

There are several "programming" environments in active 
use (for example. Interlisp [Ref. 90 , 86 , 91] ), or 

planned (for example, the Ada programming support environ- 
ment (APSE) [Ref. 93] ). Unfortunately, there is no SE 2 
which specifically supports the prototype process. This 
chapter will first describe some general characteristics of 
SE 2 s and then explain those elements of SE 2 s which are 
needed to support software design and prototyping. 

E. CHARACTERISTICS CF SOFT BARE ENGINEERING ENVIRONHENTS 
1 • D evelo pment Support Tasks 

There is general agreement that an SE 2 supports 
three development "tasks": 1) software production manage- 

ment, 2) technical aspects of software development, and 3) 
user participation in applications development [Ref. 83, 94 

, 95]. An SE 2 aids software management by "capturing" 

information about design decisions and the progress of the 
development itself. An SE 2 supports software development by 
providing automated tools. During the development of 
specific applications, the SE 2 places special emphasis on 
the role cf user-designer interaction. 



8 Problem Statement Language/Problem Statement Analyzer 
and Program Design language. A detailed review of the 
various tools and environments in current use can be found 
in Symposium on Sof t w are En q ineering En v ironm en ts , Huenke, 
edifor. 
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2 . Int sqr at ed 

An integrated SE 2 will support the three development 
tasks by unifying the tasks into an ensemble. Integration 
applies to the ease of using and the ease of documenting 
those activities associated with individual tools [Ref. 84], 
Perhaps cne of the mere important characteristics of an SE 2 , 
integration makes it easier to combine various tools in 
order to perform a specific function. 

3 . Uni for m 

A variety of automated tools are used by the SE 2 to support 
the three development tasks. For reliable operation, the 
tools must be consistent with one another [Ref. 84, 94 , 95 

, 96]. If one tool is consistent with the rest, the SE 2 

will be easier to use. It is easier to learn and use 
special formats and command structures when they are consis- 
tent among all of the tools. 

4 • Sup por t a Solu tion S trategy 

Ihe technical aspects of software development 
require the SE 2 to support two solution strategies, cne 
general and the ether specific. Generally, Soni and others 
believe that the SE 2 must support different ways of solving 
the problem. [Ref. 84]. That is, the SE 2 should support 
many different ways of solving problems. It should be flex- 
ible enough any problem-solving strategy. For the specific 
strategy, Wasserman and others believe that an SE 2 must 
support both the software life cycle model (the * waterfall' 
model) and any particular software development methodology 
which dees not diverge very much from that model [Ref. 94, 
95, 97]. In either case, the objective is the same: to 

arrive at a solution. 
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5. 



Adaptable 

Fcr practical reasons, an SE 2 should be adaptable. 
In most organizations, each of the development tasks is 
covered by different organizational groups, each with their 
own styles, attitudes, and so on. Also, the individuals 
within each group bring different perspectives to the job. 
With such a wide range of personalities, a collection of 
tools should be flexible, changeable, even extensible 
[Ref. 84]. The SE 2 should be able to adapt to the design- 
er’s (or user's) sophistication and should provide defaults. 
Defaults could be easily changed as users become mere 
sophisticated [Ref. 94, 95, 96], 

6 • F u nctio nall y Onigue 

Within each development task, there are a number of 
unigue functions. To reduce ambiguity, misunderstanding, 
and errors, tools within an SE 2 must be functionally unique. 
That is, they must have a singular purpose [Ref. 84, 94, 95, 
96], Each tcol musr be limited to a single design function. 

7 • Interactiv e 

An SE 2 must have interactive system capabilities. 
[Ref. 85, 84, 94, 95, 98]. There are two reasons fcr this: 
interactive systems aid communication among the participants 
in design, and designers can work at their own pace (inter- 
actively) rather than someone else's (batch) . User partici- 
pation, cne of the development tasks, is simplified when 
using interactive systems. 

8. R ecent Deve ler ments 

Two ideas about SE 2 s, personal development systems 
and a software engineering knowledge base, seem to unify the 
three development tasks and embody the characteristics just 
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stated. Personal development systems have all of the char- 
acteristics discussed (integrated, uniform, support a solu- 
tion strategy, adaptable, functionally unique, and 
interactive) . Their most important feature, though, is the 
dedicated support to a single designer [Ref. 89 , 94 , 95]. 

A software environment knowledge base would capture informa- 
tion about the design activity (for example, design deci- 
sions) as well as the development process (a continuous 
effort) for managers, designers, and users [Ref. 96]. This 
knowledge base would make the information easily available 
and would be done automatically. 

C. A SOFTWARE ENGINEERING ENVIRONMENT FOR PROTOTYPES 

West authors agree that a 'successful' SE 2 must support 
a certain view of the design process [Ref. 85, 94, 95, 97], 

Following the lead of Lauber [Ref. 85], a collection of 
tools, or components, which support the set of seven design 
elements of Chapters II and III, and which support the 
development of prototypes, covered in Chapter IV, is 
presented. This is followed by descriptions of how such 
components support software design principles and proto- 
typing. 

1 • T echni cs 1 Component s 

There are several components which should be 
included in an SE 2 [Ref. 62, 75, 79, 83, 101 ]. 

a. Database Management Systems (DBMS) 

A DBMS serves two purposes in an SE 2 . First, 
the OEMS enables storing and retrieving information about 
the design as well as the development process. For example, 
a record could be kept of when each version of the prototype 
was released, who designed it, relevant design decisions. 
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and so on. Second, a DBMS allows for ’quick’ design and 
programing of data handling features [Ref. 62, 61, 83]. 

Recall that the ability for quick turnaround of a working 
system tc the user is a necessary feature in many proto- 
typing situations. 

b. Generalized Input and Output Software 

Query languages, report generators, and report 
writers are often features of a DBMS (for example, FCCOS, 
RAMIS II, and NOMAD provide these features) . These features 
allow fcr easy data retrieval and data update. Report 
generators can produce complicated reports with minimal 
programming effort [Ref. 61 , 62, 79, 101 ]. 

c. Graphics Tools 

Graphics are ideal for representing the large, 
and cften complex, structures of non-trivial software 
designs. These tools are particularly suited for the oreth- 
odolcgies which use structure charts. For example. Delisle 
[Ref. 102] describes a set cf graphics- based tools, an Edit 
tool, an Evaluate tool, a Format tool, and a Clean-up tocl, 
which were developed to support Structured Analysis) . 

d. High-level Languages 

High-level languages (variously described as 
non- procedural languages, formal specification languages, 
and so on) have one objective, flexibility [Ref. 62, 83, 

101 ]. Such languages enable the designer to describe" what 
to do" rather than "hew to do" it. The system resolves the 
procedure and should produce executable machine code. The 
designer, given such a fool, can use abstraction to its 
fullest extent (the Gamma software engineering system 
[Ref. 103], for example, specifically supports abstraction). 
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e. Interactive Systems 

Devices and equipment (for example, working 
stations) which support interaction are essential [Hef. 61, 
62, 83, 98], Interactive terminals give users and designers 
the perception of rapid and efficient operation and revi- 
sion. Generally, these facilities are adapted from the host 
computer or network of the SE 2 . (Personal development 
systems could be thought of as extensions of interactive 
systems. ) 

f. Application-oriented Models 

Models are an important feature of an SE 2 . They 
are used to support human decision making [Bef. 61, 62]. 

Examples of models which are potentially useful are finan- 
cial models (as in FOCUS) or simulation models. Real-world 
modelling [Bef. 43] is also an important element in the SE 2 . 

a. Tools for Software Testing 

There is clearly a need for tools which simplify 
software testing [Ref. 83, 101]. Hausen and Muellerburg 

report that most tools of this type concentrate on verifica- 
tion and validation, that is convincing ourselves that the 
program will execute properly. They argue that software 
tools fcr program testing should cover more than just veri- 
fication and validation. They recommend a philosophy of 
quality improvement which includes quality assurance 
(defining software standards and controlling their observa- 
tion) , acceptance testing (demonstrating to the user that 
the software is acceptable for operation), and verification 
and validation. 
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2 . Supp ort for So ft wa re D esign 

Any SE 2 must be based on a particular view of- soft- 
ware design. [Ref. 65, 94, 95, 97], The view presented in 
Chapters II and III is unique, although elements of that 
view may be supported in different ways by different 
systems. 

The SE 2 must recognize, and provide facilities for, 
the symmetrical and adaptable process of design. If the 
solution tc a problem changes the problem, features of the 
SE 2 must allow revision, interactive use by clients (it is 
their problem, after all), and recor d-Jceeping, especially of 
decisions. 9 

The satisficing aspect of design may best be met by 
using the modelling tools of the SE 2 . Simulation tools can 
help answer "what if" and performance questions. Financial 

models can help decide economic questions. Planning, 

control, and estimating models can also help tc decide on 
the worth of various tradeoffs. 

The "wicked problem" aspect is particularly vexing 
in the SE 2 . High-level languages can help by allowing an 
abstract description as a formulation of the problem. The 
abstract statements are then transformed by the system into 
concrete (that is, executable) code [Ref. 105, 106, 107]. 

Communications between the user and the designer is 
aided by interactive systems. Graphics also aid user (and 
designer) comprehension. Alexander and others have shewn 
how the notion of patterns helps bridge the communication 
gap. Kuc, and ethers, [Ref. 80, 84, 108, 109, 110, 111] 

have adopted this concept in their " forms- based" software 
development environment. The 'forms' within the system are 



9 White [Ref. 104] Dresents a model for recording rele- 
vant information about design decisions durina software 
development. 
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used tc identify and define 'patterns' that are above the 
level of programming language constructs. Although a full 
discussion cf the TRIAD (TRee-based Information Analyzer and 
Developer) system is beyond the scope of this work, it is an 
excellent candidate for an SE 2 which supports software 
prototyping. 

The interactive facilities and modelling features of 
the SE 2 will help tc aid the learning process in design. 
The notion of 'learning by doing' was introduced in Chapter 
III. Tc support that notion, the SE 2 should allow the 
designer to learn, early, the consequences of a design deci- 
sion. The designer must then be given the chance to revise 
his decision, based on the 'operation' experience. 

Organizational issues must be explicitly recognized 
in ary SE 2 . First, there are organizational resources which 
are needed to support the SE 2 : programmers, operators, 

managers, space and facilities, and the computer hardware 
assocated with the SE 2 . Second, the work patterns and work 
skills cf the people who work in the SE 2 are likely tc 
change. Unfortunately, most current development environ- 
ments stress the environment over the users of the environ- 
ment [Ref. 98]. Typically, those environments have "quirks" 
which require people to adjust. The system should adjust to 
the skills and the preferences of the designers who use it 
(using, fcr example, custom default features) . If we 
consider the SE 2 as an element of a complex organization 
[Hef. 59, 60, 98], the environment's interaction with people 
is crucial; without that interaction, the SE 2 is useless in 
any practical sense. 

Finally, the SE 2 must explicitly recognize the 
evolutionary aspect of software design. The current systems 
support the waterfall model of software development 
[Ref. S4, 95]. The database management system, interactive 
facilities, and high-level languages will easily support the 
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evolutionary concept of design. Report generators and 
report writers should aid the documentation process as the 
design evolves. 

3 • Support for the Prototype Pro cess 

The process of developing a software prototype was 
covered in Chapter IV. There are four steps in that 
process: 1) identifying the user's basic requirements, 2) 

developing a working prototype, 3) implementing and using 
the prototype, and 4) revising and enhancing the prototype. 

An existing database of the SE 2 is ideal for identi- 
fying the user's initial requirements. However, there are 
problems if the database is empty. Kangasallo [Ref. 112] 
presents a model in which information requirements are 
interpreted as a set of complex queries by the database 
management system. Additional features of that model 
include a 'program constructor' which generates code based 
on the queries. A working prototype is a result of this 
mode 1 . 

Another method depends not only on the database 
management system but also on the automated tools within the 
SE 2 . Cheatham [Ref. 105] presents a system in which the 
designer and user develop an abstract model of the problem 
(possibly from the database) . Transformation refinement is 
applied (by the automated tools) which results in executable 
code--a working prototype. 

In both of these instances, the SE 2 supports the 
development of the user's basic requirments followed by an 
automated process of developing a working prototype. It is 
important that some effort be made to analyze the user's 
requirements so that reasonable queries can be made and 
reasonable models (of the problem) can be developed. 
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Other systems are available which help to develop a 
basic set cf user requirements. Some are quite complex 
[Ref. 32] ard might be difficult to integrate with the SE 2 . 

Developing a working prototype, quickly, should not 
be difficult to accomplish in the SE 2 . High-level 
languages; code generators; transformation refinement 
(mentioned above); application development systems, such as 
ACT/1 [Ref. 76] and, application generators [Ref. 75] make 
it easier to develcp working prototypes. Ideally, the 
system would be completely automated. 

An abstract model allows the designer to focus mere 
easily on the results of his or her decisions, rather than 
the implementation details. An abstract model also promotes 
flexibility when it is reused. [Ref. 105] 

Implementing and using the prototype becomes much 
easier when interactive systems are used. User interaction 
is essential and interactive terminals allow the user to 
perceive rapid operation and revision. They also help to 
speed user evaluation [Ref. 62]. 

Revision and enhancement are facilitated in the SE 2 
by using the database management system, high-level 
languages (and abstract models) , the generalized input and 
output tools, and graphics tools. The database contains a 
record cf past designs and design decisions, changes are 
easily made to abstract models and high-level language 
constructs, default values of the generalized input and 
output tools are easily adjusted, and the graphics tocls 
will enable both users and designers to spot patterns 
quickly. The user is quickly accommodated, the database 
management system automatically tracks versions and design 
decisions, and the designer is able to defer low-priority 
details without fear of compromising the design: the SE 2 

relieves the designer of much, if not all, of the drudgery 
normally associated with software design. 
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VI. CASE EXAMPLES 



The four cases which follow were chosen because in each 
there was an explicit decision began to develop and use 
software prototypes before the project began. 

A. SYMMETBT, EVOLUTION, SATISFICING, AND COHHUNICATION 

Heckel [Bef. 113] describes the process of developing a 
ptototype while designing the Craig translator. The project 
team explicitly chose to develop prototypes for several 
reasons. First, they were concerned about the problems 
which users would a ctually experience, rather than these 
problems which the designers imagi ned might be important. 
This concern is directly related to the symmetry aspect in 
design. That is, the solution and problem interrelate such 
that the solution depends critically upon the context of the 
problem. In this case, the context is the consumer’s use of 
the Translator. If the product does net perform as 
"expected", it will net sell. 

Second, the project team was interested in postponing 
decisions about restraints on the final system until they 
had to. In other words, their design evolve d. The 
designers ignored certain restrictions which had been placed 
on memory size, as long as they carefully considered the 
effects of their decisions on the production version of the 
Translator. 

Third, the project team planned to use the prototype as 
the software specification. Because they had two "versions" 
of the prototype, a black box translator and the program 
listing, they thought that they would avoid the traditional 
misunderstandings and contradictions often found in written 
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software specif icaticns. In this case, the designers were 
concerned about communications, not only between the "user” 
and the •'designer' 1 but also among themselves. 

Heckel* s description shows that the prototypes (there 
were 30 versions!) were used to clarify requirements and to 
verify the feasibility of the design. Heckel states that if 
they had been forced to make a particular design decision 
earlier than they did, they probably would have made a less 
satisfactory decision. 

The project was judged a success, although progress 
seemed slew and painful. Heckel identifies four benefits of 
developing prototypes: 

1. The project team could keep trying new things; 

2. The prototype was a good model of the final product, 
sc everyone had similar expectations about what the 
product would do; 

3. Several decisions could be postponed without 
affecting the schedule; and, 

4. The designers focused their efforts on opportunities 
rather than problems. 

The development process had some disappointments: soft- 

ware development tock longer than expected and the final 
product tcck more memory than expected. Heckel did not 
speculate on whether these "disappointments" could have been 
avoided. One interpretation is that the designers were 
unable tc meet all of their objectives and when time ran out 
their design was judged to be good enough. Thus, the 
"disappointments" can be attributed to the satisficing 
aspect of design, especially the need for more memory. The 
designers obviously made a trade-off between the "goodness" 
of the product and the amount of memory they had originally 
planned. 
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This case illu strat ed how the use of prot o ty pe s 

add r esse s the s ymme try, evolution , commun ic at io ns and 
satis ficing aspects of design. 

B. LE1BNING 

Hemenway and McCusker [ Bef . 116] describe an exploratory 
project which is leading to the development of an crder 
negotiation and entry support system for telephone service 
(the Bell system). The project is the development of the 
user interface and the supporting software for the system. 

There are two reasons given for building an operational 
prototype: 1) to evaluate the user interface and 2) to 

assess the feasibility of a particular software architec- 
ture. Even though the reasons coincide with two uses of 
prototypes (that is, to clarify user requirements and to 
verify the feasibility of a design) they are related tc two 
aspects cf design. The aspects are learning and communica- 
tion between the designer and user. 

Prototypes of the software were developed to determine 
whether a table-driven system could be designed. Prototypes 
cf the user-interface were used to determine whether the 
user-interface would substantially increase the length of 
time service representatives spend on orders (compared to 
manual crder entry ard search). 

The case concludes by stating that the results of the 
prototype evaluation led to making several recommendations 
to the designers of the first release of the system. H ence . 
the p roto type served to hel p the desi gner s learn m ore about 
thei r sol ution and th eir problem . 
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C. SICKED EBOBLEMS, COMMUNICATIONS, AND THE ORGANIZATIONAL 

CONTEXT 

Jenkins [Ref. 114] discusses how the decision tc develop 
a prototype led to successful development of an automated 
data processing facility for the Congressional Budget 
Office. 

Two aspects of software design are apparent in this 
case: 1) communications between users and designers and 2) 

the organizational context of the system. Communications 
between the designers and users was greatly improved by 
using a prototype. Bather than try to decide on the design- 
er* s effectiveness by reviewing written specifications, 
managers witnessed operating demonstrations. The prototype 
also shewed non-technical users what it was possible to do 
in their application areas with the new tools. 

By far the most important aspect illustrated by this 
case, is the concern of the designers for organizational 
issues. The Congressional Budget Office serves the needs of 
the Ccngress, admittedly a complex organization. So, the 
designers needed immediate responses to Congressional 
inquiries, because when information is needed, it is often 
needed immediately or its value is lost. 

This organizational aspect is also closely related to 
wicked problems. Becall that wicked problems refer tc 
social system problems which are ill-formulated, where the 
information is confusing, where there are many clients and 
decision-makers with conflicting values, and where the 
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ramifications in the whole system are thoroughly confusing. 
Clearly Congress is faced with these kinds of problems. 
There is every reason to expect that the Congressional 
Budget Cffice deals with similar problems when responding to 
Congressional inquiries. 10 

The case presented b;y J en kins illustra tes how p rot o types 
can aid software d e sign when faced with critical orga niza - 
tional i ssu es a nd wic ked Problems. 

D. COMMUNICATION, LEARNING, AND EVOLUTION 

Groner and others [Ref. 115] present a case cf using 
prototypes tc clarify the user's requirements. The case is 
unusual because it started with a proposal from outside the 
user's community. The designers set out tc determine if and 
how computer technology could meet the information 
processing needs of medical researchers. 

This case is a clear illustration of the importance of 
communications between the designer and the user and the 
representation used for communicating. 

Prototypes were required in the requirements analysis 
phase because without concrete, working examples our 
potential users could not be sure that computer systems 
are needed, what functions they should perform, or how 
they wculd use them. [Ref. 115 ; p. 100*] 

Less clearly stated is the implication of learning 
during the design process. The intitial design of the 
prototype was based on the designer's knowledge about 



10 Consider the fluctuations from Congress to Congress, 
chairman to chairman, committee to committee: from year to 

year, week to week, and even from hour tc nour during the 
Budget Committee markup sessions [Ref. 114 : p. 22]. 



8 1 



needs for 



information processing 
Subsequent versions were improved 
comments frcm clinical researchers, 
pants 



medical research, 
based on use by and 
The project pa'rtici- 



. . . agreed to learn about each other's disciplines, 

then define problems and attempt no devise and evaluate 
solutions in collaboration with others in the taraet 
user community. [ Bef . 115 : p. 101] 

The project used an incremental implementation strategy 
(evolution) under which major software releases were sched- 
uled approximately every four months. Several hundred soft- 
ware changes were made over a period of a year and half. 
This case shows how prototypes can be used to create the 
final system. 1 1 

The case pr e se n ted by G roner and others is an exe s llen t 
exam p le of hew c cm m u nicati ons, lear ning, and evoluti on are 
inte rtw ine d in software design . The development cf p roto - 
type s helped all of the de sig n p art i cipants cope with thos e 
aspe cts cf sof tware design . 

E. SOMMAEY 

These cases illustrate how prototypes help designers 
cope with the seven aspects of design which were covered in 
Chapters II and III. In each of the cases, the authors 
point to success. For Heckel, the prototypes led to a 
product that was easy to use, had a number of useful 
features, and was implemented on a single-chip micropro- 
cessor. 



liThe case description leads the 
"production" system was not developed 
that the prototypes evolved into tne 



reader to think that a 
. Every indication is 
production system. 
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Hemenway and McCusker say only that prototype evaluation 
led to recommendations to the designers. From this, we can 
safely infer that the prototype aided the designer ' s ‘under- 
standing of the problem. 

Fcr Jenkins, the overall assessment to the prototype was 
positive. Managers liked the idea of a prototype because 
there was nc prior commitment to a particular course of 
action. 

Groner and others believe that the greatest benefi* of 
the prototype is that the prototypes are concrete, working 
examples cf computer systems which are meeting everyday 
needs . 
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VII. CONCLU SIO NS 



A new view of design was presented in Chapter II. This 
view identifies a sat of seven interrelated and mutually 
dependent elements which were found in the literature. 
Support for these elements was found throughout the computer 
and information science literature. The set of seven 
elements explains how best to cope with the problems, ambi- 
guity, and uncertainty associated with software design. 

The process of developing a software prototype is 
presented as the most appropriate way to incorporate the 
design elements into software design. In fact, the proto- 
type process exploits certain elements, such as communica- 
tion between the user and designer, to improve the overall 
design of the software. 

Cne of the more important conclusions is that software 
designers, especially designers of large-scale systems, have 
much to learn from designers in other fields. The software 
design literature shews little evidence of influence from 
other design fields. This work is a start toward that 
needed transfer of knowledge. 

The software prototype may be the sensible way tc design 
large-scale systems. Recall that complex design problems 
have been called wicked problems. If some large-scale 
system developments are ‘more wicked' than others, then 
developing prototypes seems to be the only way to design the 
syste m. 

Software prototyping enables users and designers to cope 
with ill-defined problems and changing requirements. Past 
experience indicates that bad technical engineering is not a 
problem with software development. Rather, unsati sf actory 
design decisions ard faulty information are the real 
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a mechanism which 



problems. Software prototypes provide 
allows designers to test their decisions and to learn mere 
about the problem. The prototypes also allow users a 
construcyive environment in which to express their satisfac- 
tion cr dissat isfacticn and a stimulant in learning hew to 
deal with their problems. 

Software prototypes, however, present special difficul- 
ties because -hey are not the universal remedy for software 
design problems. Careful management is needed to ensure the 
software ptototype is really designed and net just put 
together. Careful thought and planning are necessary before 
coding begins. Managers, designers, and users must remember 
that a software prototype is an experiment. Judgement and 
commitment are needed to control endless iterations. 
Managers must have the wisdom to know when to step. Often, 
while developing successive prototypes, there is a tendency 
to delay formally documenting the system. While this 
problem is net unique to prototypes, there must be attentive 
management and commitment to ensure adequate and complete 
documentation. 

In spite of these cautions, evidence indicates that 
developing and using software prototypes is the best option 
for ccping with software design problems, for ensuring the 
system is delivered, and for ensuring a satisfied user 
population. 
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VIII. RECOMMENDAT ION S FOR FURTHER STUDY 



A. MANAGEMENT 

Developing software prototypes presents management with 
some unusual problems. Many of our current management tech- 
niques depend on getting the project done right the first 
time (Ref. 117]. As we are well aware, this seldom occurs. 
Research is needed to assess the effect of prototype devel- 
opment on management. 

1. Hew does the manager decide when to cease development 
of prototypes? When is the project ended? 

2. Hew dc managers deal with increased communications 
between users and designers? If special management 
controls are needed, how far should they go? 

3. What management style best suits managers of software 
prototype projects? 

4. How is the project budgeted and controlled? Hew is 
progress measured? 

B. ACQUISITION AND CONTRACT MANAGEMENT 

Current acquisition and contract management procedures 
and regulations for software appear to be lass than satis- 
factory, within the Federal Government generally, and the 
Department of Defense particularly. Even as these proce- 
dures and regulations are changing, there is some evidence 
that the traditional model of software development may 
become reguired. The Department of Defense has begun to 
address the concept of software prototypes in the DoD 
Software Technology Initiatives [Ref. DoD81 : p. 69-71], but 
this research appears to be concerned only with requirements 
specifications. 
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1. Hew can or bow should acquisition and contract 
management procedures and regulations accomodate the 
principles of design and software prototypes? 

2. What is the best strategy for encouraging acceptance 
of the software design principles and software proto- 
types? 

3. How might the elements of software design and devel- 
oping software prototypes help with the acquisition 
and contract management for embedded computer 
resources? 

C. OBGANIZ&HON AL CCHTEXT 

Kling and Scacchi [Ref. 59, 60] reviewed a large number 

of organizational studies while developing their views about 
the effect of computer systems upon organizations. When 
their ideas are considered within the context of software 
prototypes, further research is needed. 

1. How will chances in theories of organizational devel- 
opment affect the process of developing prototypes? 

2. Is any one organizational theory best suited for 
software design and software prototypes? 

3. What are the social dynamics of software design? 

4. What are the social dynamics of developing software 
prototypes? 

D. QUALITY 

A fundamental part of design is to satisfy the needs for 
quality. Rooke [Ref. Rook82] has concluded that design is 
the mest important factor in determining overall quality. 
Even though one of the objectives of developing software 
prototypes is to achieve user satisfaction (a major element 
of quality) , research is needed to determine how prototypes 
can affect software quality. 
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1. If we accept that prototypes will affect a change in 

software technology, how will that change influence 
our perceptions of quality? That is, will software 
prototypes lead users to expect more than can be mer? 

2. How might the concept of Quality Circles fit the 

process of developing software prototypes? 

3. To what extent will software prototypes influence 

software quality? Since prototyping requires 

concensus, who is ultimately responsible for product 
quality and liability? Should anyone be “ultimately" 
responsible? 

E. REPRESENTATION 

The software prototype is the ultimate representation of 
the user’s requirements. The written specification anchors 
the other end of the representations scale. 

1. What other types of representations can aid software 
design and the development of software prototypes? 

2. What methods are suitable for represenring abstrac- 
tions when identifying a user's requirements before 
developing a software prototype? 

3. Hew do different representations affect our percep- 
tions and real world knowledge? Can different, 
initial rapr e sentari ons lead to quicker design and 
development of software prototypes? 
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